为什么照片整理会成为负担？

读完这篇文章，你能建立一套"停用 6 个月也不会崩溃"的照片管理系统。

你的手机里有 15000 张照片，但你找不到上周拍的发票。更糟的是，每次想整理，打开相册就关掉——任务太重，不知从何下手。问题不在你懒，问题在于你用"管理代码"的方式管理记忆。

照片不是代码

大多数人整理照片的思路来自工作文件的惯性：追求命名规范如 2024-01-01-001.jpg，设计目录层级如 /旅游/日本/东京/，担心删除会破坏"系统完整性"。这套方法对代码有效，对照片是灾难——照片和代码是两类完全不同的数据。代码精确性优先、顺序敏感、需要人工维护结构、文件名承载含义；照片回忆性优先、顺序无关、自动生成元数据、文件名无意义。

类比：整理照片像整理衣柜——你不会给每件衣服编号，只会按季节分大类，靠记忆和视觉找。照片是时间锚点，不是工程产物。

三个设计原则

基于上述差异，照片整理遵循三条原则：目录极简，仅按年份划分，不嵌套子目录，不重命名文件——迁移成本为零，20 年后仍可读，无需维护；元数据驱动，每张照片自带拍摄时间、GPS 坐标、设备参数、图像指纹，这些 EXIF 信息不需要写进文件名，它已经在那儿了；合理分工，文件系统负责存储备份，管理软件负责索引检索，AI 负责聚类分类，你只判断哪些值得保留。

Photos/
├── 2023/
├── 2024/
└── 2025/

# EXIF 元数据示例：照片自带所有你需要的信息
from PIL import Image
from PIL.ExifTags import TAGS
img = Image.open("photo.jpg")
exif = {TAGS[k]: v for k, v in img._getexif().items() if k in TAGS}
print(exif['DateTimeOriginal'])  # 输出：2024:01:01 14:32:05

反模式：连续编号

2024-01-01-001.jpg
2024-01-01-002.jpg
2024-01-01-003.jpg  ← 删除这张，后面的全要改

这套命名法有三个问题：断号焦虑——删除一张序列就断了；维护成本 O(n)——改一张后面全要改；云服务冲突——iCloud、Google Photos 会自动重命名。健康做法：用原始文件名，依赖时间戳排序。

零维护照片流

• 摄入：手机自动同步到 /Photos/YYYY/，关闭所有重命名选项
• 处理：每月 10 分钟，批量删除模糊和重复照片，给重要的加星标
• 检索：按时间线浏览，用人脸识别找人，用地理标签筛选地点
• 检验：问自己——如果停止整理 6 个月，系统会崩溃吗？会的话，重构它

理想的照片系统应该像呼吸一样——自然存在，不消耗注意力。好的管理系统不是让你更勤奋，而是让你可以安心地懒惰。